SOA with .NET and Windows Azure : System.Transactions

Distributed Resource Transactions

A single resource transaction involved a single object and a single database, as shown in Figure 1. It was basically implemented in ADO.NET using an explicit programming model.

A distributed resource transaction, on the other hand, may have had two or more objects that interacted with each other, along with two or more database resources (Figure 2).

Prior to System.Transactions, the most common means of implementing DTCs was via .NET Enterprise Services (as discussed previously in this chapter). Specifically, the System.EnterpriseServices namespace was used.

This had several disadvantages:

• It forced a class to inherit from the ServicedComponent class, which then required the assembly to be signed and registered in the GAC. This practice was time-consuming and difficult to maintain, thereby raising the barrier to using transactions.

• It forced the use of distributed DTCs, even when a single object or a single resource was involved. The overhead imposed a noticeable performance cost.

• It required administering the component in COM+ services, which was cumbersome.

• .NET Enterprise Services transactions were tightly coupled to COM+ design considerations, forcing applications to factor in just-in-time activation, object pooling, state-aware programming model, and so on.

System.Transactions was introduced to alleviate these problems and to provide a simpler programming interface.

Some of its features included the following:

• It supported both single-resource transactions and distributed resource transactions and was incorporated directly into the CLR.

• The System.Transactions namespace supported any resource manager that could speak either OLE transactions or the broadly adopted WS-AtomicTransaction protocol.

• It contained classes that allowed you to write your own transactional application and resource manager and create and participate in a transaction with one or more participants.

• The System.Transactions infrastructure supported transactions initiated in SQL Server, ADO.NET, MSMQ, and the MSDTC.

Explicit and Implicit Programming Models

System.Transactions included both explicit and implicit programming models. The explicit programming model was implemented using the Transaction class and the implicit programming model was based on the TransactionScope class.

The Transaction class was used to pass the transaction to the System.Data class or the database. The TransactionScope class was used to scope a code section into a transaction, as shown here:

Example 1.

using System;
using System.Transactions;
class Program
{
  static void Main(string[] args)
  {
     using (TransactionScope ts = new TransactionScope())
     {
       ts.Complete();
     }
  }
}

In this example, calling the Complete() method results in the transaction being committed. If an exception was thrown inside the using construct, the TransactionScopeComplete() method was called (resulting in the transaction being rolled back). would be disposed before the

Ambient Transactions

System.Transactions further introduced the concept of “ambient” transactions. An ambient transaction was a transaction executed by code. Ambient transactions could be referenced using the Current property of the Transaction class. Transaction.Current flowed around with the code and was referenced as follows:

Example 2.

Transaction ambientTransaction = Transaction.Current();